$location support for pushState - #1675

what's the fallback strategy for browsers that don't support pushState?

in general I'm not opposed to this change, it still needs a lot of polish, tests and figuring out the fallback story.

I think the user needs to add a polyfill for the fallback.

Thanks for the feedback. I am still committed to polishing this but may not have time for a few weeks.

This PR has not been update in 2 months and seem sot be incomplete solution. In order to keep our PR queue relevant, I am closing this PR. Once you fix it up, please resubmit. Also sign the CLA

In order for us to be able to accept it, we ask you to sign our CLA (contributor's license agreement).

CLA is important for us to be able to avoid legal troubles down the road.

For individuals (a simple click-through form):
http://code.google.com/legal/individual-cla-v1.0.html

For corporations (print, sign and scan+email, fax or mail):
http://code.google.com/legal/corporate-cla-v1.0.html

I'd be willing to take over this work but I'd like to have your feedback first, if possible so that it doesn't get rejected.

Polyfill for older browsers would have to implement the whole of navigating browser history which is not easy. One of the most popular project that does it, History.js, does it by appending hashes of state objects to URLs which requires significant code size (6 KB minified & gzipped).

The question is: would it be possible to add this feature while making note IE9 and older are not supported with this methods? I personally work more & more on projects dumping IE8 and older completely and IE9 already has way lower market share than IE8 and it's going quickly down as most IE9 users are auto-updated to IE10.

This should work for Google projects as well because Google policy is to fully support only the current and previous versions of each browser and once IE11 goes out in a few months, this means dumping IE9 which makes pushState available in all supported browsers.

What do you think? Any other ideas?